Graphical user interfaces typically employ some form of a window manager to organize and render windows. Window managers commonly utilize a window tree to organize windows, their child windows, and other user interface controls to be displayed within the window such as buttons, menus, etc. To display the windows on a display screen, a window manager will parse the window tree and render the windows and other user interface objects in memory. The memory can then be displayed on a video screen. A window manager may also be responsible for “hit-testing” input to determine in which window input was received. For instance, when a user moves a mouse cursor into a window and “clicks,” the window manager must determine the window in which the click was made and generate a message to that window.
When creating an entirely new window manager, it is typically necessary to create new user interface controls, otherwise known as visual objects, which can be utilized by the window manager. For instance, it may be necessary to build new buttons, pull-down menus, and other visual objects that are compatible with the new window manager. However, creating an entirely new set of user interface controls can be extremely time consuming and difficult. Moreover, creating an entirely new set of user interface controls for a new window manager seems wasteful considering that there are thousands of user interface controls available for use with previous window managers.
Methods exist for hosting legacy user interface controls within new window managers. However, these previous methods suffer from several serious drawbacks. In particular, these previous methods are unable to handle messages intended for the legacy user interface controls without requiring window sub-classing or modifying the user interface message loop to pre-translate messages. Moreover, existing methods either require changing sources of the existing controls, or severely limit the integration of the existing controls. Requiring the sources to be changed prevents using existing controls without modification, a severe problem for the thousands of existing user interface controls available in the market today. Another previous solution is to expose the existing user interface control as a “foreign” object. This, however, requires other controls to treat that object with special knowledge and calling different application programming interfaces (“APIs”). Accordingly, these previous methods are unable to handle messages intended for legacy user interface controls in a high-performance and robust manner.
Therefore, in light of the above, there is a need for a method and apparatus for adapting and hosting legacy user interface controls that can utilize a legacy user interface control in a new window manager without requiring window sub-classing or modifying the message loop to pre-translate messages. There is a further need for a method and apparatus for adapting and hosting legacy user interface controls that can utilize legacy user interface controls in a new window manager without requiring modification of the controls or treating the controls differently than native controls.